-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Updated php.ini-production to reflect recommended defaults. bug 73726 #2238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
yet unfinished port to libmagic 5.28 catch with missing libmagic port pieces regenerate data file with magic from 5.28 test magic files from 5.28 missing files fix path pure c99 is still not supported move right to 5.29, yet some bugs present more sync with orig lib more ZMM usage use unpatched data for now partial revert according to bug #67705 Revert "more ZMM usage" This reverts commit 5e3c9b8. several fixes, so it's now closer to the clean port
Note the behavior change, FILEINFO_CONTINUE will now always append a string \012-. I'm leaving this as is for now, as this is the behavior change in libmagic.
* PHP-7.0: add test for bug #57547
* PHP-7.1: add test for bug #57547
* PHP-7.0: Fix int/size_t confusion in isValidPharFilename (bug #73580)
Now the conversions are explicit and do checks. Not sure it's the best way but at least we can see them now in the open.
Would advise you leave revalidate_freq at the current default, as well as fast_shutdown (it is known that this can cause strangeness). |
Thx, will do.
@krakjoe Could you elaborate, when/why this might lead to problems.. ? we should mention those situations in the .ini comments... |
IMO default enablement should not be done. Not only because not all the scenarios do require it. It depends very much on a concrete system and goals. Fe, there might be collisions with other zend_extension's. While having more comments is good, the php.ini should be worky when just dropped in without reading any comments, which in experience often the use case :) So it'd be safer to leave such decisions up to a conscious user while keeping the entrance verge low for anyone. Thanks. |
OK, so I think it's best at this point to try to gather consensus on internals about this change, really we want dmitry to say this is okay, or this is not okay, and we want him to update the PECL extension to reflect whatever changes we decide are necessary. |
I am also fine to disable opcache by default, but at least the buffer sizes/memory settings should reflect the recommendations. symfony for example suggests see also https://www.scalingphpbook.com/blog/2014/02/14/best-zend-opcache-settings.html thx for your feedback. |
I did some testing on ubuntu14lts with php7.0.14 test with http://symfony.com/blog/introducing-the-symfony-demo-application (using symfony 3.2.1) requires...
test with https://github.com/bestmomo/laravel5-3-example (using laravel 5.3) requires...
values determined as described in I guess the interessting numbers are
current default for hope those numbers are enough, or do we need more? My proposal for the new defaults are |
They look like reasonable suggestions to me, thanks for the effort. @dstogov we need your input here, please review. If we get no response, I'll just merge it in a few days and assume dmitry is okay with it, although ideally pecl should mirror these changes and I have no permission to update that. |
TODO: Update programmatic defaults
Increasing opcache.max_accelerated_files, opcache.interned_strings_buffer and opcache.memory_consumption makes sense. opcache.enable_cli=1 didn't make practical benefits before PHP-7.1, but since PHP-7.1, new optimizer significantly improves speed of some CLI applications. So, this may make sense. opcache.fast_shutdown may cause some incompatibilities. |
@dstogov thanks for input, glad to see you back from holidays :) @staabm we can now move forward ... Please update defaults (in code and ini) to reflect changes suggested by dmitry for 7.0 on this PR. |
With opcache.file_cache enabled opcache.enable_cli does make quite a
difference in 7.0:
First time (empty file cache):
$ time composer >/dev/null
real 0m0.040s
user 0m0.032s
sys 0m0.004s
Second time:
$ time composer >/dev/null
real 0m0.019s
user 0m0.016s
sys 0m0.000s
With opcache disabled:
$ time php -d opcache.enable=0 /usr/local/bin/composer >/dev/null
real 0m0.033s
user 0m0.032s
sys 0m0.000s
|
But for the file cache we need a configured directory, no? |
@staabm it does, but filling up tmp with files is not a good idea ... so we can't enable file cache by default whatever. |
@krakjoe I deleted my initial comment a few mins after posting it, as I realized it does not have a php-ini default see https://php-lxr.adamharvey.name/source/xref/master/ext/opcache/zend_accelerator_module.c#318 |
I wouldn't recommend enabling file cache by default. |
@dstogov ACK, we don't plan too :) |
As a note, about Opcache and CLI, came across this kind of bug yesterday, again https://bugs.php.net/bug.php?id=73879 . Well, seems it happens no matter it's in default ini, or not :) Thanks. |
something went wrong while changing the merge base... will create a separate PR with the changes required. |
@staabm ack, closing ;) |
suggesting changes as per https://bugs.php.net/bug.php?id=73726 to use more sane defaults[1] for the bundled php.ini-production config.
I guess some of those changes also need a code-change somewhere in a c-file?
As mentioned in the initial bug report, I guess we could even use bigger values for those defaults as "modern" servers provide way more memory.
[1] https://github.com/zendtech/ZendOptimizerPlus/blob/master/README#L44
TODOs